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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

This document specifies the stage 1 requirements for realisation of an Open Service Access (OSA). 

OS A enables applications to make use of network functionality through an open standardised interface (the OSA API). 
OSA provides the glue between applications and network functionality. In this way applications implementing the 
services become independent from the underlying network technology. 

Applications which make use of network functionality offered through the OSA interface are not standardised by 3GPP. 

The network functionality offered through the OSA interface may or may not be standardised by 3GPP. 

OSA is one toolkit, amongst others, that enables certain aspects of the requirements of the Virtual Home Environment 
(VHE) concept to be realised. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

2.1 Normative references 

[1] Void 

[2] 3GPP TS 22.101: "Service principles". 

[3] 3GPP TR 21.905: "Vocabulai-y for 3GPP Specifications". 

[4] 3GPP TS 23.107: "QoS Concept and Architecture". 

[5] 3GPP TS 22.024: "Description of Charge Advice Information (CAI)". 

[6] 3GPP TS 29.198: "Open Service Architecture; Application Programming Interface". 

[7] 3GPP TS 22.141: "Presence Service Stage 1". 

[8] 3GPP TS 22.228: "IP Multimedia Subsystem (IMS) Stage 1". 

[9] 3GPP TS 22.071: "Location Services (LCS) Stage 1". 

[10] 3GPP TS 29.240: '3GPP Generic User Profile (GUP); Stage 3; Network' 

2.2 Informative references 

[10] World Wide Web Consortium Composite Capability/Preference Profiles (CC/PP): A user side 

framework for content negotiation ( www.w3.org ) 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access Rules: For the definition see [7]. 

Applications: software components providing services to users by utilising service capability features. 

Application Interface: standardised Interface used by applications to access service capability features. 

Availability: a property of a user denoting his/her ability and willingness to communicate based on factors such as the 
identity or properties of the requester of the information and the preferences and/or policies that are associated with the 
user. This property may be computed through information available from various capabilities within the network 
including (but not necessarily) the presence service. 

Call: A logical association between several users pertaining to the CS CN domain.. 

Charging: A function whereby information related to a chargeable event is formatted and transferred in order to make 
it possible to determine usage for which the charged party may be billed. 

HE-VASP: Home Environment Value Added Service Provider. For the definition see [3] 

Home Environment: For the definition see [3] 

IM : IP Multimedia. For definition see [8] 

IM Session: For definition see [8] 

Local Service: For the definition see [3] 

Personal Service Environment: For the definition see [3] 

Policy: is a formalism that may be used to express business, engineering or management criteria. A policy is 
represented by a set of rules. Rules are expressed as condition(s)-actions(s) pairs. When the conditions associated with a 
rule are satisfied the associated actions are executed. 

Note: Policies created by applications are matched against the policies of a Network. 

Policy Event : A policy event is associated with the action part of designated rule(s). The event is generated when the 
action part is executed. 

Policy Management: is the capability to create, modify and delete policy related information, including policy events. 

Policy Enabled Service: is a Service which has some or all of its properties expressed in terms of policy rules. E.g. 
Charging Service wherein charging criteria are expressed in terms of policy rules 

Policy Decision Point: A function of the network where the applicable policy is chosen. 

Policy Enforcement Point: A function of the network where the chosen policy is applied. 

Policy Repository: A function of the network where policies are stored. 

Policy Enabled network: is a network that supports at least one instance of a Policy Repository and Policy Decision 
Point and Policy Enforcement Point. 

Presence Service: For the definition see [7]. 

Presence Information: For the definition see [7]. 

Presence Entity (presentity): For the definition see [7]. 

Service Capabilities: bearers defined by parameters, and/or mechanisms needed to realise services. These are within 
networks and under network control. 
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Service Capability Feature: functionality offered by service capabilities that are accessible via the standardised 
application interface. 

Service Provider: an organisation which delivers services to the subscriber. This can be e.g. the operator of the 
subscriber's Home Environment or an authorised VASP. 

Note: In the context of this specification it is assumed, that at least one application providing the services of the Service 
Provider makes use of OS A functions 

Services: a service is the user experience provided by one or more applications. 

User: For the definition see [3] 

Virtual Home Environment: For the definition see [3] 

Watcher: For the definition see [7]. 

Watcher Information: For the definition see [7]. 

Further 3G related definitions are given in 3G TR 21.905 [3]. 

3.2 Abbreviations 

For the purposes of this TS the following abbreviations apply: 

API Application Programming Interface 

CAMEL Customised Application For Mobile Network Enhanced Logic 

HE Home Environment 

PS Packet Switched 

PSE Personal Service Environment 

VHE Virtual Home Environment 

OSA Open Service Access 

SCF Service Capability Feature 

MExE Mobile Execution Environment 

Further 3G related abbreviations are given in 3G TS 21.905 [3]. 



General Description of OSA 



In order to be able to implement future applications/end user services that are not yet known today, a highly flexible 
Framework for Services is required. The Open Service Access (OSA) enables applications implementing the services to 
make use of network functionality. Network functionality offered to applications is defined in terms of a set of Service 
Capability Features (SCFs). These SCFs provide functionality of network capabilities which is accessible to 
applications through the standardised OSA interface upon which service developers can rely when designing new 
services (or enhancements/variants of already existing ones). 

The aim of OSA is to provide a standardised, extensible and scalable interface that allows for inclusion of new 
functionality in the network with a minimum impact on the applications using the OSA interface. 



5 The role of OSA within the VHE framework for 

services 

The goal of standardisation in 3GPP with respect to services is to provide a framework within which services can be 
created based on standardised service capability features. 3GPP services will generally not rely on the traditional 
detailed service engineering (evident for supplementary services in second-generation systems), but instead provides 
services using generic toolkits. 

OSA is one of these toolkits, standardised within 3GPP, for the support of services within 3GPP system (see chapter 
5.1). 
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Services can be implemented by applications using service capability features, which are accessible via the OSA 
interface towards these SCFs in the network. 



Applications supporting services I 



I 



Standardised OSA 
Application Interface 



service 

capability 

features 

Service 
capabilitie: 




Figure 1 : Applications access Service Capability Features 
via the standardised OSA Application Interface 



5.1 Physical location of applications using the OSA interface 

The physical location of applications accessing the OSA application programming interface is an implementation 
matter. This TS places no requirements on the physical location of the applications accessing the OSA application 
programming interface. 

The only requirement on such applications accessing the OSA apphcation programming interface is that they shall only 
do so via the framework for services. 

The architectural support of the OSA application programming interface shall permit applications access to the OSA 
API independent of where the applications are physically executing. 



High level requirements to OSA 



The following high level requirements apply to the OSA apphcation programming interface (API). The standardised 
API shall be: 

independent of vendor specific solutions; 

independent of programming languages, operating systems, underlying communication technologies, etc. used 
in the service capabilities; 

secure, scalable and extensible; 

independent of the location where service capabilities are implemented; 

independent of supported server capabilities in the network; 
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independent of the transport mechanism between the service capabiHty features server and the application server; 

It shall be possible for an OSA application to continue operation in case of a consecutive upgrade of the 
underlying OSA capabilities. This ability to operate may be limited to a specific time period which is managed 
by the network operator. 

Access to Service Capability Features shall be realised using modem state of the art access technologies, e.g. 
distributed object oriented technique and Web Services technologies might be considered.; 

- OSA shall be aligned as far as possible with equivalent and related work in other bodies, such as, OMA, Parlay 
and JAIN; 

OSA shall allow applications access to home network service capability features. Access to Service capability 
features in another network shall be possible.; 

When access to Service capability features in another network or administrative domain exists, the following 
requirements apply: 

The application shall not be aware that the SCF is in another network 

The SCF shall not need to support additional functionality in order to be accessed from a different network 

The network providing the SCF shall be able to control the visibility and usage of the SCF by another 
network. 

It is not required that network entities, which provide the implementation of OSA interfaces (SCFs), be 
mappable to 3GPP standardised functionality, nor that the existence of a standardised interface / protocol to 
communicate with 3GPP standardized network elements is required. Thus it is permissible to e.g. build a OSA 
API function into a WAP gateway to retrieve terminal capabilities from terminal supporting the WAP protocol. 

Note: If the network entity, to which OSA provides an API interface, is a 3GPP standardised entity and if a 
standardised interface / protocol to communicate with that network entity exists it is recommended that 
3GPP defines a mapping of the OSA API functions to that interface / protocol. 

OSA shall allow Service Capability Features to communicate with backup instances of an application in the case 
where the primary application instance is not responding. This shall be possible also when the primary and 
backup instances of the application are physically located in different locations. 

OSA shall enable an operator to set policies (e.g. based on the need of load distribution) on how OSA shall 
utilize the underlying network system. 



7 Void 

8 Charging requirements 

The charging functionality of OSA allows an application to raise a charge against a subscriber's account for goods and 
services provided to her. It enables the invoicing, by the operator, of soft (e.g. download of software, music,...) and hard 
goods (e.g. CDs, books,...), which potentially are provided by third parties. 

Additionally, the charging functionality of OSA shall provide for the maintenance of non-monetary subscriber accounts. 
An application may add or deduct non-monetary units to or from these accounts. 

The responsibility for the subscriber accounts can be assigned to either the home network or elsewhere.: 

• If the home network does not handle the accounts itself, charging requests are sent from the home network (and 
possible other applications) to a dedicated charging application, typically a charging centre. This case is out of 
scope of OSA. 

• If the accounts are handled by the home network, the operator takes care of them. 

They may be used to charge for network resource usage (call charging, as it is done today) as well as any non- 
telecommunication related activity (any E-commerce activity like service usage, online purchases...) 
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OSA shall provide sufficient fiinctions to support charging when the accounts are handled by the home network. 

Two cases need to be considered in more detail: 

Call, Session and Event Charging: OSA shall enable applications to control the charge of a call, a session (PS 
Session or IM Session) and / or an event that is under supervision of this application. OSA shall allow an 
application to provide additional charging information to the network; 

Service Usage (e.g. Online Purchases): On the other hand, OSA shall allow to employ the charging capabilities 
of the network to charge subscribers for any kind of service or even online purchases. Calculation of the charge 
may be based on monetary and/or non monetary grounds. 

Beyond this, there are general charging functions on subscriber accounts (monetary and non-monetary) that shall be 
available via OSA: 

• Query the current account balance and current reservations. 

• Monitor account access (send notifications if charges or recharges are applied to a subscriber"s account). 

• Retrieve the history of the transactions 

9 Requirements on interfaces at different levels of 
abstractions 

The OSA-defined functions may be accessed through interfaces at different levels of abstractions and according to 
different programming formalisms, in addition to those defined in the previous Releases. The abstraction levels and the 
programming formalism should be identified according to the needs of the programmers' communities. Those interfaces 
should consist of a simplified version of the already standardised OSA APIs or consist of new APIs for additional 
capabilities defined according to the Web Services principles (e.g.. Parlay X, OMA). 

All the interfaces shall be integrated in the context of the OSA architecture: 

they shall guarantee a secure and controlled access to the service capabilities; 

it shall be possible to introduce them in an incremental way; 

they should allow applications be triggered by network events. 

The interfaces shall be defined using state of the art specification formalisms (e.g., UML, WSDL), and realised using 
different distributed processing technologies. 

10 Security and Privacy requirements 

10.1 Security requirements on User Profile Management 

The User Profile Management functions shall be able to grant or deny access to individual parts of the subscriber" s User 
Profile. 

The User Profile Management functions shall ensure that all operations on parts of User Profile data are authorized. 

The type of access is one out of: 

Reading user profile information; in case parts of the User profile is subject for reading it shall unambiguously 
be identified by the application. 

Adding information to the user profile. 

Modify existing information in the user profile. 
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The control of access rights is in principle on the user's discretion. The user shall have the possibility to allow or restrict 
the retrieval and presentation of her user related data. The mechanism how a user is able to maintain access rights is for 
further study. 

When using the OSA framework to access user profile information, the Generic User Profile APIs [10] shall be re -used. 

10.2 Privacy requirements on Subscriber Identity 

It shall be possible to hide subscriber"s identity towards the OSA Applications and replace it with an alias. For each 
OSA Application, the alias shall be unique identification that has a one-to-one relationship to the network asserted 
identity (e.g. MSISDN, IP address, SIP-URI) of the subscriber and may be permanent or temporary (e.g. session based); 
those aliases can be used as parameters in the OSA APIs. 

Note: Liberty Alliance and OASIS specifications on Identity Management and Identity Federation (e.g. SAML 
2.0) needs to be taken into account to address issues related to subscriber identity. 

10.3 Topology hiding 

It shall be possible to hide the topology of the underlying network systems. 
It shall be possible to provide a single point of access to the Applications. 



1 1 Requirements for Policy Management 

Applications shall have the ability to interact with policy-enabled Service Capability Features in a secure manner. The 
network policies always take precedence over the application defined policies. 

The OSA interface shall provide sufficient capabilities to enable applications to request: 

To manage the application"s policy-related information 

This allows applications to create, modify and delete policies, policy events and to activate, deactivate and 
modify policy rules. Policy rules may be expressed with simple data types (such as integers or string) or more 
complex data types (such as Boolean values, time, lists, meta-variables..etc). Expression of policy rules shall 
take into account these complex data types as well as allow for a feature rich set of operands and allow for 
ability to define user specific functions. 

To manage policy event notification 

This allows applications to register for specific policy events. Once registered for such events, the application 
shall receive notification of the events until it explicitly requests the termination of the notification request 

To collect policy statistics 

This allows an application to collect policy related statistics from the network. Examples include success or 
failure of operations on policies and time stamps of policy events. 

To request policy evaluation 

This allows an application to request that a set of policies is evaluated by the network. 



12 Event Notification Function 



The Event Notification Function shall allow an application to specify the initial point of contact which it is interested in. 
The Event Notification Function provides the necessary mechanisms which enables an application to request the 
notification of subscriber or network related event(s). An application may in addition request the cancellation of 
subscriber or network related event notification. 

For all subscriber related events the Event Notification Function shall support two ways for an application to subscribe 
to notifications: the application shall either specify the subscriber for which the Event Notification Function is valid or 
indicate that it is ready to receive user related notifications for any subscriber. The application may be responsible for 
the explicit provisioning of the subscriber related event notification or it may leave the provisioning of the notifications 
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to the Home Environment operator and just indicates that it is ready to receive notifications. An application may use 
both mechanisms at the same time. Once an appHcation has enabled the notification of event(s), the Event Notification 
Function shall report the event(s), including the identification of the user to which the event applies, until such time the 
application explicitly requests the termination of the event(s) notification. 

When the event occurs, the application that requested the event is informed.. The notification of the event shall be 
accompanied by unambiguous information identifying the original request and event related data.. For example, in case 
of an application is interested in 'message' the notification to the application shall indicate whether it is incoming or 
outgoing, in case of chargeable events, the application shall receive details as used at the network to create a Call Detail 
Record. In this case, processing in the network is not suspended after notification of the event to the application. 

The Event Notification Function includes the availability of offering additional criteria to be specified by the 
application. The set of criteria is individual and may vary for the event requested. The detailed set of criteria available 
for each of the events below are described in [6]. 

12.1 Subscriber Related events: 



• A call processing event occurs. 

when a call to or from a given user changes state and this event is armed by an application, that application 
shall be notified. 

• A message is sent or received. 

when a message to or from a given user is sent or received and this event is armed by an application, that 
application shall be notified. 

• A chargeable event happens. 

when a chargeable event occurs for a given user and this event is armed by an application, that application 
shall be notified. 

• The user's status is changed. 

when a subscriber registers to a network or when a given user changes her status (e.g. from idle to busy) and 
this event is armed by an application, that application shall be notified. Registration in this sense is further 
detailed in the chapter on User Status Functions. Attach and detach applies for CS and PS. 

• The user's location is changed. 

when a given user changes her location (e.g. leaving a certain area which is 'identifiable' by the network) and 
this event is armed by an application, that application shall be notified. 

• The Terminal Capabilities are changed. 

when the capabilities of a terminal change (e.g. when a keyboard is attached) and this event is armed by an 
application, that application shall be notified. 

Note: The ability to support this function is dependent on the ability of a terminal (through e.g. MExE or WAP) 
to notify changes in its capabilities. Therefore this function will not be able to supply event notifications 
for terminals not supporting notification of their terminal capabilities. 

• An event occurs which affects the quality of service configured for the user. 

an application can register with the service for notifications about network events that affect the quality of 
service configured on the end user"s connection. Whenever such events occur, the service generates 
notifications to inform the application about the impact that these events had on the QoS features set up on 
the end user"s connection. 
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12.2 Network Related Events: 

• A network fault management condition is met, 

when a fault management condition occurs at the underlying network (e.g. congestion of network 
components) and this event is armed by an application, that application shall be notified. 

• A network service or network service capability registers, 

when a network service capability feature registers with the Framework all applications which have 
subscribed to this event and are currently authorised to use this service capability feature shall be notified. In 
case there is already a service capability feature of the same type that is in use, all applications which are 
authorised and have subscribed to recieve information about this event will be informed about information 
related to backward compatibility between the new service capability feature and the version currently in use. 
This information allows an application provider to have an indication about the effort on his side required in 
migrating from the older to the newer version. 

• A network service or network service capability de -registers, 

when a network service capability feature de -registers with the Framework all applications which are 
currently authorised to use this service capability feature shall be notified. 

12.3 Other Related Events: 

• A change in presence related information. 

If any presence related information changes (such as one or more presence information attributes or a user"s 
availability), and this event is armed by the application, that application shall be notified. Presence 
information may be associated with a user, device or service, or any abstract entity that has the ability to 
report presence information. 

• A chargeable event happens. 

when a chargeable event occurs, which will be charged to the application provider and this event is armed by 
an application, that application shall be notified. 



13 Functions offered by OSA 



Functions that are offered by OSA shall be applicable for a number of different business and applications domains 
(including besides the telecommunication network operators also service provider, third party service providers acting 
as HE-VASPs, etc.). 

All of these businesses have different requirements, ranging from simple telephony and call routing, virtual private 
networks to fully interactive multimedia to using MS based applications. 

Service Capability Features: 

Application/Clients access OSA functions in terms of service capability features via the standardised application 
interface. This means that service capability features are accessible and visible to application/clients via the 
method/operation invocations in the interface. 

Service capability features shall be defined as much as possible in a generic way to hide the network specific 
implementation. To achieve this, it is necessary to identify the functionalities that can be provided in different ways by 
the use of different service capabilities. For example. User Location can be produced in several underlying ways.Each 
of these functionalities can then be defined as a single generic function and the different underlying service capabilities 
are not visible to the application. It is important that the generic part becomes as large as possible to enable applications 
to use functions without the need for knowledge of the underlying network capabilities 

When applications use the generic service capability features, these applications become independent of the network 
domain ie network agnostic. Applications shall however still be able to request service capability features specific to a 
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service capability (e.g. Call Setup from CAMEL) or specific to a particular network domain. This will increase 
dependency of the application on the used service capability while providing improved optimisation. 

Note: The grouping of OS A functions into Service Capability features is out of scope of this document. 

Three different types of OSA functions can be distinguished: 

Framework functions: provide commonly used utilities, necessary for access control, security, resilience and 
management of OSA functions; 

Network functions: these shall enable the applications to make use of the functionality of the underlying 
network capabilities. 

User Data related functions: these enable applications to access data of a particular user. Such data are e.g. the 
status of the user, her location or data in the user"s User Profile. 

13.1 The Framework functions 

The framework provides the essential capabilities that allow OSA applications to make use of the service capabilities in 
the network. The framework shall support the ability for applications to access SCFs in another network. 

There are four distinct features that comprise the framework: Trust and Security Management, Service Registration and 
Discovery functions. Integrity Management and Service Subscription. 

13.1.1 Trust and Security IVIanagement 

The trust and security management feature provides the necessary mechanisms which define the security parameters in 
which client applications may access the network. This includes the availability of a framework initial access point 
through which all client applications are authenticated and authorised and the ability to allow the signing of on-line 
service level agreements between the client applications and the framework. 

13.1.1.1 Authentication 

Authentication is used to verify the identity of an entity (user, network, and application). 
Three types of authentication are distinguished: 

• User-Network Authentication: 

Before a user can access her subscribed applications, the user has to be authenticated by the network that 
provides access to the application. This allows the network to check to what applications the user has 
subscribed to. User-network authentication is handled within the network and therefore outside the scope of 
the OSA . 

• Application-Network Authentication: 

Before an application can use the capabilities from the network, a service agreement has to be established 
between the application and the network. Establishment of such a service agreement starts with the mutual 
authentication between application and network. If a service agreement already exists, modification might be 
needed or a new agreement might supersede the existing. 

• User- Application Authentication: 

Before a user can use an application or perform other activities (e.g. modifying profile data) the application 
must authenticate the user. When the network already authenticates the user, authentication is not needed 
anymore. When the network is transparent and the user accesses an application directly, authentication is 
needed between user and application. This is outside the scope of the OSA. 

13.1.1.2 Authorisation 

Authorisation is the activity of determining what an authenticated entity (user, network, and application) is allowed to 
do. 
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NOTE: Authentication must therefore precede authorisation. 
Two types of authorisation are distinguished: 

• Apphcation-Network Authorisation: 

Verifies what non-framework functions the application is allowed to use. Once an application has been 
authorised to use one, more or all non-framework functions no further authorisation is required as long as the 
"allowed" non-framework functions are used. 

• User- Application Authorisation: 

The application verifies what actions the user is allowed to perform (e.g. deactivation of functionality, 
modification of application data). This is transparent to the network and therefore outside the scope of the 
present document. 

1 3.1 .1 .3 Policy for service capability features access and usage 

The framework shall provide functions to manage and enforce policies on the access and usage of service capability 
features requested by the OSA Applications, in addition to the policies implemented by the Service Capability Features 
themselves (e.g. through policy-enabled Service Capability Features). Examples of such policies are: number of 
application requests for a specified period, frequency of application requests, check on syntax correctness and validity 
in term of lifetime for parameters, check if the requestor (OSA Application and/or subscriber) is in arrears. 

13.1.2 Service Registration feature 

The Registration function enables the non-framework service capability features (i.e. service capability features that 
contain non-Framework functions) to register with the Framework. Registration must take place before authorised 
applications can find out from the Framework which non-framework service capability features are available. This 
means that the non-framework service capability features must be registered before they can be discovered and used by 
authorised applications. The service capability feature is finally registered if the registration process is successfully 
completed. 

Note that only the non-framework service capability features have to be registered. The Framework service capability 
features (containing only Framework functions) are available by default since they provide basic mechanisms. 



13.1.3 Service De-Registration function 

The De-Registration function enables the non-framework service capability features (i.e. service capability features that 
contain non-Framework functions) to de -register with the Framework. When a service capability feature de -registers 
the service capability feature shall discontinue providing service to all applications. Further, the service capability 
feature can no longer be discovered. 

13.1.4 Service Discovery feature 

The Discovery function enables the application to identify the total collection of service capability features that it can 
use. Upon request of the application, the Discovery function indicates the non-framework service capability features 
that are available for use by the application. The list of available service capability features is created through the 
Registration process described in subclause 12.1.2. This means that a service capability feature must be registered at the 
Framework before it can be discovered by the application. 

13.1.5 Integrity Management function 

Integrity management provides the means to allow the framework to query and report conditions that relate to the 
integrity of the framework, the network service capability features and the client applications. Furthermore an 
application may query conditions that relate to the integrity of the framework ad the network service capability features 
and report on it"s own conditions. As part of the integrity management functions, the framework may provide: 

• supervision of the status of client applications to ensure continued operation, a process known as heartbeating. 
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• fault management reporting and control. Specific examples include the ability for the framework to notify 
applications of internal fault conditions as well as faults in the network service capability features and the 
ability for applications to request specific test executions in the framework. 

• operations and maintenance access, more specifically, the ability for the application to synchronise with the 
system date and time. 

1 3. 1 .5a Service Subscription function 

This function represents a contractual agreement between an Enterprise Operator and the Framework. In this 
subscription business model, an enterprise operator fulfils the role of subscriber/customer of services and the client 
applications act in the role of users or consumers of services. The framework itself acts in the role of retailer of services. 

13.1.6 APIs Usage Accounting 

The framework shall provide functions to supply information for accounting of the usage of APIs. 

13.1.7 Support for Identity Management Framework 

The Parlay OSA framework shall provide support for Identity Management. This shall take into account frameworks 
such as Liberty Alliance identity management framework. 

13.2 Network functions 

The Network functions represent the total collection of network resources. 

The following subclauses define generic network functions e.g. for Message Transfer. 

13.2.1 Call and Session Control functions 

This subclause details with Call and Session Control functions. The purpose of this function is to allow applications to 
control and monitor calls, packet switched sessions and IM Sessions. 

The application may request the quality of service when first negotiated at the start of the call and may also request the 
network to notify the application of any changes in QoS (conversational, background, interactive and streaming class - 
see [4]) which take place during the call. 

For QoS information, the Call and Session Control Functions allow applications to monitor the amount of used traffic 
channels and bandwidth (e.g. for HSCSD) and used timeslots (e.g. for GPRS). 

1 3.2.1 .1 CS Call Control functions 

This subclause details with circuit switched call control functions. The purpose of this function is to allow applications 
to control and monitor calls. 

Applications should have the ability to : 

• Release Calls: 

This provides the ability for the application to force the release of a call. The application may provide an 
indication of the reason for release of the call. 

• Control Calls: 

This provides the ability for an application to modify the information pertaining to the call at the time of 
establishment of the call. The application may also allow the call to continue with or without the modified 
information pertaining to the call. The application shall have the ability to request call events of the call 
under control to be observed by the network and reported back to the application. 

• Request call information: 



£75/ 



3GPP TS 22.1 27 version 9.0.0 Release 9 1 8 ETSI TS 1 22 1 27 V9.0.0 (201 0-01 ) 

This provides the abihty for an appHcation to request information relating to the call of interest specified in 
advance. Requested information includes at least call duration, call end time. 

• Monitor calls: 

This provides the ability for an application to monitor for call duration and tariff switching moments. An 
application may specify a threshold for the duration of a call or a part thereof. The application shall have the 
ability to grant new thresholds when the expiry of a previously set threshold has been reported to the 
application. When an event is subject to be monitored and the event is met, the application shall get informed 
accompanied with sufficient information. 

• Presentation of, or restriction of, information associated with a party involved in a call (e.g. calling line ID, 
calling name); 

• Relinquish control over a call 

This allows an application to relinquish control over a call but still allowing the established call to continue. 
Once the control of the call has been relinquished, the application may not be able to regain control over that 
caU. 

• Interact with a user 

This provides the ability for an application to interact with a user. An application may be able to send specific 
information to the user and may request the collection of data from the user. Sending information to the user 
or collecting information from the user shall be supported when the user is engaged in a call (e.g. USSD, 
DTMF) or call-unrelated (e.g. USSD, SMS). The information sent to the user may include an indication of an 
announcement, text or user specific data. 

Note 1 : Call related user interaction may e.g. be used to play/record/customise user specific announcements while 
through call-unrelated user interaction e.g. service preferences may be managed. 

For each call it shall be possible to specify: 

the events on which monitoring is required ([10]). 

Note 2: The mapping to service capabilities is for further study (it shall be investigated to which extend the 
requirements above fit to CAMEL, MEXE and other service capabilities). 

1 3.2.1 .2 PS Session Control functions 

This subclause details with PS session control functions. The purpose of this function is to allow applications to control 
and monitor PS sessions. A PS Session may consists of one or more GPRS PDP context. 

Applications should have the ability to : 

• Release a PDP context: 

This provides the ability for the application to force a PDP context to be released. The application may 
provide an indication of the reason for release of the PDP context. 

• Control a PDP context: 

This provides the ability for an application to modify the information pertaining to the PDP context at the 
time of establishment. The application may also allow the PDP context to continue with or without the 
modified information pertaining to the PDP context. The application shall have the ability to request events 
to be observed by the network and reported back to the application. 

• Monitor a PDP context: 

This provides the ability for an application to monitor for PDP context duration and tariff switching 
moments.. An application may specify a threshold for the duration of a PDP context or a part thereof. The 
application shall have the ability to grant new thresholds when the expiry of a previously set threshold has 
been reported to the application. 

• Monitor a PS session: 



£75/ 



3GPP TS 22.1 27 version 9.0.0 Release 9 1 9 ETSI TS 1 22 1 27 V9.0.0 (201 0-01 ) 

This provides the abihty for an apphcation to monitor for PS session data volume. An appHcation may 
specify a threshold for the amount of data allowed to be transferred within a PS session. The application shall 
have the ability to grant new thresholds when the expiry of a previously set threshold has been reported to the 
application. 

1 3.2.1 .3 IM Session Control functions 

IM Session Control 

Create IM Sessions 

The application shall be able to establish IM sessions between two or more parties with certain media 
capabilities. The application may add or remove parties at any time for any session. An application may add 
additional sessions with certain media capabilities between any parties already involved in an session. Sessions 
with multiple parties may lead to the creation of a multi-media Conference Call. This can either be an ad-hoc 
conference creation or it can refer to resources that were reserved in advance. 

Release IM Sessions 

This provides the ability for an application to force the release of an IM session. This may be limited to the 
release of certain parties from the session or may be the release of all the parties. 

Relinquish control over an IM session 

This allows an application to relinquish control over IM sessions. 

Party join/leave control 

The application shall be informed when a new call party wants to join/leave the conference. It shall be possible 
for the application to allow or reject the inclusion of the new party to a conference. 

Presentation of, or restriction of, information associated with a party involved in a session (e.g. caUing line 
ID, calling name); 

Media Control 

Control media channels 

The application shall have the ability to control media channels originated by (or on behalf of) a user or media 
channels terminated to a user. This control includes, but is not limited to the barring of a media channel request, 
allowing the media channel establishment to continue with or without modified information, addition or removal 
of additional media channels, temporarily suspend a media channel (place on hold), open, close or modify the 
parameters of the media channels. 

Relinquish control over specific media channels 

This allows an application to relinquish control over the media stream. When it relinquishes control over certain 
media channels it does not lose control over the entire session. 



Reserve/Free conference resources 

The application shall be able to reserve resources in the network or free earlier reserved resources for a 
conference in advance. 

Information 

Request Notification of Media channel events 

The application shall be able to request notification of certain events associated with a type of media channel. 
Events include, but not limited to: a user initiating or closing a session, an incoming IM session request to user 
or a terminating user unable to accept an incoming IM session request. 

Monitoring of Media channels 

The application shall be able to request all the media channels currently available on a IM session In addition the 
application must be able to monitor the opening and closing of channels for media for a specified session. 
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13.2.2 Void 

13.2.3 Void 

13.2.4 Cinarging functions 

Call and Event Charging 

Call and Event Charging functions enable the application to instruct the network and inform the user with charging 
information and to add some additional charging information to the network generated Call Detail Records. Some of the 
following charging facilities are available only if the network either controls the account or has access to it. 

The OSA Call and Event Charging function shall enable an application to: 

define and manage thresholds (e.g. session duration, data volume) for a call; 

provide additional charging information to be included in the Call Detail Record. This may contain information 
transparent to the network; 

transfer Advice of Charge data (as defined in [5]) to the terminal. 

Service Usage 

These charging functions shall enable applications to augment subscriber accounts maintained by the network and to 
charge subscribers for using services. These applications are not necessarily telecommunication related. In addition to 
charging subscribers for service usage, these functions could also be used for payments in an online purchase scenario. 

Provided, that these functions are supported by the underlying network an application shall be able to: 

Check, if - for the service to be provided by the application - the charge is covered by the subscribers account or 
credit limit 

Reserve - for the service to be provided by the application - a charge in the subscribers account, that can be 
deduced from the account after service delivery. 

Deduct an amount from the subscriber"s account. If a reservation has been made earlier, this amount should be 
taken from the reserved amount. 

Request the network to split the deduction of an amount among several subscribers accounts or other chargeable 
entities according to a specified partitioning. It shall be possible to notify an individual subscriber's account or 
other chargeable entity about the percentage of the total amount, to which the deduction has been performed 
Note: this requirement also covers the case when the total amount to be deduced is calculated by the network. 

Release a reservation acquired earlier. If part of a reservation has been deducted already, just release the 
remaining reservation. 

Add non-monetary units to a subscriber"s account. 

Deduct non-monetary units from a subscriber"s account. 

Reverse a completed charge transaction, e.g. after repudiation. 

The functions for charging application usage shall meet the following general requirements: 

Hide payment policy (e.g. prepaid/postpaid) from applications 

Hide payment type (credit card, cash, bank withdrawal) from applications 

Hide subscriber"s identity towards the application. This would provide anonymity (like for prepaid customers). 

Support prepaid subscribers. This requires that the application immediately gets informed if the subscriber"s 
account covers the service usage costs. If not, the application may reject serving the subscriber. 

Allow for Multi-currency support. This shall allow service providers to request charging in their preferred 
currency 



£75/ 



3GPP TS 22.1 27 version 9.0.0 Release 9 21 ETSI TS 1 22 1 27 V9.0.0 (201 0-01 ) 

General Account functions 

These functions provide access to sensitive data. They shall be restricted to client applications that had been granted 
additional privileges via suitable means, i.e. as authorised by the framework function. 

The OSA general Account function shall enable an application to: 

retrieve a transaction history of a subscriber" s account, this may include 

the retrieval of a list of monetary or non-monetary amounts that have been debited from or credited to a 
subscribers online account, 

the request of additional information on the specific transaction (e.g. the application or service description 
provided with the actual transaction). 

check a subscriber" s current account balance. 

monitor the subscribers account and may request to get informed of any change. 

ask the charged user for an explicit, interactive confirmation before any charging operation is performed. The 
General Account function will support a procedure to obtain confirmation by the user. Such a procedure shall be 
under the control of the network. 

Note: There is no requirement to standardise this procedure. 

In case an application retrieves a list for a subscribers" transaction history, it shall specify the time interval for which 
the transaction history shall be retrieved. 

13.2.5 Void 

13.2.6 QoS management functions 

The OSA interface shall provide functionality to enable an application to dynamically change the quality of service 
available on the end user connection. 

• An application may request to change the default quality of service available on the end user"s connection. 

• An application may request to change the quality of service available on the end user"s connection on a 
temporary basis 

• Applications are able to view transaction history and current quality of service status for reasons such as self- 
care. 

QoS features are defined within the network and may be managed and shared beforehand with application providers, 
with a clear indication as to which of these can be used as default QoS features and temporary QoS features. 

13.2.7 Service Request Capabilities 

The application shall have the ability to request a particular type of service, for example CS-video, or IP-voice, or 
Communication Service. If an application requests a particular type of service, the underlying network has the right to 
reject such a request and instead offer a default service. The application shall have to ability to receive notifications and 
events related to the service running in the underlying network. 

1 3.3 User data related functions 
1 3.3.1 User Status functions 

The User Status functions enable an application to retrieve the user's status, i.e. to find out on which terminals the user 
is available. 

The following functions shall be provided: 
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- retrieval of User Status: 

the application shall be able to retrieve the status of the user (e.g. the user is busy, her terminal is attached, or 
detached). 

- notification of User Status Change: 

the application shall receive notifications when the user's terminal attaches or detaches: 

detach: the user's terminal is switched off or the network initiates detach upon location update failure; 

attach: the user's terminal is switched on or there has been a successful location update after network 
initiated detach. 

the application shall receive notifications when the user"s status moves from idle to busy, or from busy to 
idle. 

Attach and detach applies for CS and PS. 

The application shall be able for each terminal to start/stop receipt of notifications. 

13.3.2 User Location functions 

The User Location functions provide an application with information concerning the user's location. 

The user location information contains the following attributes: 

location (e.g. in terms of universal latitude and longitude co-ordinates); 

accuracy (value depending on local regulatory requirements and level of support in serving/home networks; 
note that the accuracy of the serving network might differ from that in the home environment); 

age of location information (last known date/time made available in GMT). 

The following functions shall be provided: 

- report of location information: 

the application shall be able to request user location information; 

by default the location information is provided once; the application may also request periodic location 
reporting (i.e. multiple reports spread over a period of time). 

- notification of location update: 

the application shall be able to request to be notified when the user's location changes, i.e. when: 

the user enters or leaves a specified geographic area; 

the user's location changes more than a specified lower boundary. The lower boundary can be selected 
from the options provided by the network. 

- emergency call location: 

automatic network location during emergency call provided to application; 

retrieval of current location based on emergency call details. 

The application shall be able for each user to start/stop receipt of notifications and to modify the required accuracy by 
selecting another option from the network provided options. 

- Access control to location information: 

the user shall be able to restrict/allow access to the location information. The restriction can be overridden by 
the network operator when appropriate (e.g. emergency calls). 
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When an application requests report of location information or notification of location update, it shall be possible for the 
application to provide an optional requestor identiy, an optional service identity and an optional codeword (as defined in 
[9]). If an application provides one or more of the above optinal privacy information, the information shall be brought to 
the location service capabilities attention and used to comply with privacy policies of the subscriber the request relates 
to. 

13.3.3 Void 

13.3.4 Void 

13.3.5 Terminal Capabilities functions 

The Terminal Capabilities functions enable the application to determine the capabilities of the user's terminal . 

Note 1: The ability to support this function is dependent on the ability of a terminal (through e.g. MExE or WAP) 
to notify its terminal capabilities. Therefore this function will not be able to supply terminal capabilities 
for terminals not supporting notification of their terminal capabilities. 

Note 2: "Terminal" covers both (mobile) equipment and USIM. 

The following functions shall be provided: 

- retrieval of Terminal Capabilities: 

the application shall be able to retrieve the capabilities of the terminal. This includes: 

the media that the terminal is capable to deal with (e.g. audio, video, ; this information is needed by the 
application e.g. when the user wants to download messages from the mailbox); 

the number of calls/sessions that the terminal can deal with simultaneously. 

13.3.6 Void 

13.4 Void 

1 3.5 Presence related capability functions 

13.5.1 Relationship to Release 6 Presence Service 

Void. 

13.5.2 Functions 

The OSA interface shall allow an application access to presence capabilities within the network. Presence related 
information may be requested or supplied by an OSA application and may include, but not limited to presence 
information pertaining to the presence service as described in [7] or user availability. 

An OSA application may act as a requester of presence information (i.e. act as a watcher) and/or act as a supplier of 
presence information (i.e. act as a presentity). All the capabilities offered to presence service watchers and presentities 
are described in [7] and may be offered to OSA applications. In addition to the authorisation performed by the OSA 
Framework, the presence service checks that the application is permitted to access the presence service. 

An OSA application may manage or query availability status and/or preferences of a user which may be associated with 
one or more services (e.g. voice call, IMS sessions, MMS ...etc.). Such availability may be determined from a range of 
existing capabilities. 

The following OSA capabilities shall be supported for an application: 
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- register as a presentity and/or watcher: 

the application shall be able to request the registration as a presentity and/or as a watcher in the presence 
service. This registration shall include the ability to establish as well as cancel a registration. 

- supply presence related information to the network: 

the application shall be able to supply and/or update presence related information (presence information or 
availability) at any time. An application may modify the availability of a user. - request the querying 
and/or modification of presence related data: 

the application shall be able to request the querying and/or modification of data other than presence 
information related to watchers and/or presentities. Such data includes, but is not limited to any access rules 
pertaining to the presentity to be modified. An application may be able to request the management of 
availability preferences of a user. Management includes the setting, modification and deletion of availability 
preferences. 

- request Presence related Information : 

the application shall be able to request presence related information. The application shall be able to request 
presence information about a presentity or may request the availability of a user. Such requests may be for 
the current information, on a periodic basis or for future changes in the presence related information (e.g. 
arming of event notifications). 

- retrieve watcher information: 

the application shall be able to request watcher information about a presentity. 

- manage presence agents: 

manage and maintain the dynamic presence information and capabilities associated with presence agents. 



13.5.3 Presence Compatibility 

Parlay OSA APIs shall be maintained and updated in accordance with ongoing industry work, specifically 
OMA Presence-SIMPLE and XDM and within IETF WGs SIP and SIMPLE. 

13.6 Void 

13.7 Multimedia Messaging function 

The Multimedia Messaging function enables applications to receive and send multi-media messages. 

1 3.8 Content Management function 

OSA shall provide Content Management functionality. 

The Content Management function enables an application to introduce content into the network and handle the content 
lifecycle. Contents may be consumed by other applications or users. 

The OSA Content Management function shall enable an application to: 

- upload contents onto the network; 

- delete content that resides in the network; 

- receive notification of events related to the uploading or deletion of own content 

- update the content description information that resides in the network; 

- retrieve content description information from the network; 
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- receive notification of events related to content from other applications, based on content description information 
keywords; 



14 Service Brokering Function 



OSA Service Brokering support requires API level capabilities like Service Selection, Service Provisioning, Feature 
Interaction and Service Chaining. The concept of Service brokering in this context is the ability to package, provision 
and supply a set of applications or services onwards to the application server implementing the business logic that 
requires the use of such a service broker functionality within an OSA environment. 

Service broker function shall enable the delivery of multiple services in an operator network in a managed and 
controlled fashion. Therefore whenever an event occurs, there is a need to ensure that the set of applications or services 
that may act upon that event are invoked in a manner that does not conflict with any other application or service defined 
in the provisioned package of applications or services. 



OSA Service Brokering API should be capable of supporting the following features; 

Provisioning and Management of all data necessary to support OSA service brokering 

Evaluation of OSA service brokering data to control execution of service scenarios 

Service Brokering should support OSA SCS Service Brokering and OSA Application Service Brokering. 

Note 1: Examples where an OSA service brokering solution may apply include: 

A network event such as a call trigger may result in the need to resolve conflicts between different 
OSA applications and related service delivery platforms. 

An OSA SCS may receive or generate an event that requires the use of further OSA SCSs, for 
example Policy Management, Charging etc., transparent to the application using the SCS. 

An OSA SCS may generate an event that may result in the need to resolve conflicts between multiple 
OSA applications. 

Note 2: Requirements for the service brokering between OSA and non-OSA applications are FES. 
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Annex A (informative) : Use cases 



This informative annex describes how the OS A functions described in the normative section of this document could be 
used to deploy enhanced multimedia services. 

A.1 Travel support and information service 

Service Scenario Description 

The service scenario described below is the following: a user has subscribed to a tourist board information service, and 
each time he will enter a new interesting location the service provider will offer him to watch a video showing the main 
attractions of the area. The service is charged 1 Euro per movie. 

Step bv step description 

Note: The following description does not imply any physical location of the different functions, or any mapping 
between the SCFs and the network capabilities. The processes internal to the different entities are not 
detailed. 

FF: Framework Function 

NF: Network Function 

UF: User data related Functions 



Step 1: On-line Service Level Agreement 

This step is intended to sign an on-line service level agreement (SLA) between the information service and the 
framework. 



♦ 



Service 
Provider 



OSA SCFs 



FF - Application-Network Auttientication 
■* ► 



The Framework 
is authenticated 



The Service Provider 
is authenticated 



FF - Apphcation-Network Authorisation 
M ► 



The hst of non-framework functions the application is 
allowed to use is established. SLA is signed. 



Step 2: Service initialisation 

The Service Provider will discover all the service features available in the network (e.g. location update, service usage 
charging. . .), and set up the parameters necessary to render the service (i.e. the service provider asks to be notified 
whenever the user enters a specific geographic area). The list of available service features depends on the SLA. 

Note: It is assumed that all the available Service Capability Features have already registered. 



Step 3: Service Delivery 

The service provider is informed that the user has entered a new geographical area (e.g. Japan). After checking that the 
user has enough money left on his account, the service provider retrieves the terminal capabilities. Based on this 
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information, the service provider can determine the type of content that can be sent to the user (for example a black and 
white video if the terminal does not support colour display, . . .). The service provider will then reserve 1 € in the account 
of the subscriber. A multimedia session will be established between the service provider and the user, and the user will 
then be displayed the sightseeing information. Once the movie" s display is over, the session will be released and the 
service fee will be deducted from the user"s account. 



♦l 



Service 
Provider 



OSA SCFs 



UF - Report of Location Update 

NF - Cliarging Function - Service Usage - Check solvency 

UF - Retrieve Terminal capabilities (media available, screen size...) 




r \ 

The service provider 
identifies which type 
of video can be 
delivered to the user. 
V 



NF - Charging Function - Service Usage - Reserve 
NF - Create Multi-media session 



NF - Release Multimedia Session 




NF - Charging Function - Service Usage - Deduct 1 Euro 



A.2 



Void 



A.3 Access to SCFs in another network 

Service Scenario Description 

Two operators, a wireline operator A and a wireless operator B, belonging to the same telecommunication group, have 
adopted OSA solutions. Each of them introduced in its service platform an OSA Gateway, to provide to application 
layers (also in 3rd party domains) a relevant subset of capabilities implemented in its network. 

Let assume that a corporate is implementing a rich VPN-like service by exploiting the features provided by the wireline 
operator (i.e., the corporate subscribed a subset of the SCFs provided by wireline operator). If such a corporate wants to 
enhance its application with the capability to handle with SMSs sent/received by the members of its VPN (e.g., its 
employees) and the wireline operator does not provide any appropriate network capabilities, according to the current 
specifications, the corporate must subscribe the needed SCF (e.g., a User Interaction implemented through SMSs) 
provided by another operator (e.g., the wireless operator B). But in this case, the corporate must deal with two 
subscriptions, its VPN application must cope with two OSA Gateways; in addition, the corporate could select a different 
wireless operator, not belonging to the same group of the operator A. 
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Administrative Domain 1 



Administrative Domain 2 



Operator A 



Operator B 



Figure 4: Operator A and Operator B relationship 

Such a situation could be dealt by enhancing the OSA specifications in order to allow the OSA Gateways belonging to 
A and B to be 'federated', in order to allow the subscribers to the OSA Gateway in A to access also, in a controlled way, 
the service capabilities provided by the OSA Gateway in B. This means that the applications do not have to deal with 
the complexity of handling two OSA Gateways, the application service provider does not have to open a new customer 
relationship with another operator, and the operator A has not to introduce additional service capabilities in its 
infrastructure. 
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